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DETAILED ACTION 

1. Claims 1-64 have been examined. 

Double Patenting 

2. The nonstatutory double patenting rejection is based on a judicially created 
doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the 
unjustified or improper timewise extension of the "right to exclude" granted by a patent 
and to prevent possible harassment by multiple assignees. A nonstatutory 
obviousness-type double patenting rejection is appropriate where the conflicting claims 
are not identical, but at least one examined application claim is not patentably distinct 
from the reference claim(s) because the examined application claim is either anticipated 
by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 
F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 
USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 
1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 
F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 
USPQ 644 (CCPA 1969). 

A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) 
may be used to overcome an actual or provisional rejection based on a nonstatutory 
double patenting ground provided the conflicting application or patent either is shown to 
be commonly owned with this application, or claims an invention made as a result of 
activities undertaken within the scope of a joint research agreement. 

Effective January 1 , 1994, a registered attorney or agent of record may sign a 
terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 
37 CFR 3.73(b). 
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3. Claims 1, 3-7, 9, 10, 14, 20-22, 25, 27, 28, 34-37 and 59 are provisionally 
rejected on the ground of nonstatutory obviousness-type double patenting as being 
unpatentable overclaims 108-113, 128, 129, 135-142, and 154 of copending 
Application No. 09/513,440. Although the conflicting claims are not identical, they are 
not patentably distinct from each other because it would have been obvious to one of 
ordinary skill in the art at the time of invention to provide method claims with system 
claims. 

This is a provisional obviousness-type double patenting rejection because the 
conflicting claims have not in fact been patented. 

Specification 

4. The abstract of the disclosure is objected to because of undue length (the 
abstract should be 150 words or less). Correction is required. See MPEP § 608.01(b). 

5. The disclosure is objected to because of the following informalities: the phrase 
"such as system" in para 72; the phrase "As shown in Fig. 9A2, is an example..." in 
para. 176; the word "bespoke" in para 178; the phrase "If the neither" in para. 182; a 
close parenthesis is missing at the end of para. 186; the phrase "will be generated a 
some..." in para 234. 

Appropriate correction is required. 



Claim Rejections • 35 USC §112 

1 . The following is a quotation of the second paragraph of 35 U.S.C. 112: 
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The specification shall conclude with one or more claims particularly pointing out and distinctly 
claiming the subject matter which the applicant regards as his invention. 

2. Claim 1 is rejected under 35 U.S.C. 112, second paragraph, as being indefinite 

for failing to particularly point out and distinctly claim the subject matter which applicant 

regards as the invention. Claim 1 is indefinite because there is no outcome from the 

risk filter routine specified in the claim. 

Claim Rejections - 35 USC § 102 

6. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that 
form the basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(b) the invention was patented or described in a printed publication in this or a foreign country or in public 
use or on sale in this country, more than one year prior to the date of application for patent in the United 
States. 

7. Claims 1-23, 25-57, and 62-64 are rejected under 35 U.S.C. 102(b) as being 
anticipated by U.S. Patent No. 5,717,989 to Tozzoli and Lynch. 

Regarding applicant claim 1: 

A computer-implemented method of reducing risk in a payment-based transaction 
wherein payment is made from an account holder to a Counterparty using a payment 
bank system operated by a payment bank, the method comprising the steps of: 
Tozzoli and Lynch disclose: 

A computer implemented system (col. 1, lines 5-6) of reducing risk 
for payment transactions (col. 6, lines 43-44), where payment is made with 
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the use of a "trade system," supervised by a funder (col. 5, lines 47-49), 
who authorizes and makes payments. 

a. receiving at least one user-supplied risk parameter associated with the 
Counterparty; 

The funder is responsible for setting credit limits as part of the 
account parameters (col. 5, lines 61-62). This is accomplished using a 
central facility with communication interface to remote locations (col. 4, 
lines 63-67 and col. 5, lines 1-10). 

b. receiving a first instruction authorizing payment from the account holder to 
the Counterparty ; 

Use of a purchase order that provides instructions to authorize 
payments from the funder to the buyer (col. 5, lines 36-42). 

c. storing the first instruction in a payment queue; 

Purchase order data is stored on a computer, where "...subsequent 
action data about a subsequent action in fulfillment of the contract..." can 
take place (col. 3, lines 49-55). Storing lines of instructions from a 
purchase order would represent a payment queue. Storage is provided by 
the trade system (col. 4, line 67). 
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d. during processing of the payment transaction, performing a risk filter 
routine that determines whether to selectively reject payment authorized by the 
first instruction based upon the at least one user-supplied risk parameter 
associated with the Counterparty. 

"The trade system... verifies that each portion of a transaction 
properly relates to the purchase order and criteria established by the 
funder and possibly by the trade system, in a process referred to herein as 
filtering, and generates payment instructions at appropriate times." (col. 5, 
lines 39-43). Filtering is considered a "risk evaluation function." (col. 6, 
lines 37-44) Also, the system maintains a balance for buyer and seller (col. 
8, lines 13-19), which can be shown against a credit limit (col. 10, lines 42- 
55), where the payment can be accepted or rejected (col. 7, lines 54-58) 

Regarding claim 2 and 23: 

(Claim 2) The computer-implemented method of claim 1 , further comprising the step of: 
generating the at least one user-supplied risk parameter on a user system and 
communicating the at least one user-supplied risk parameter to the risk filter routine. 
(Claim 23) The computer-implemented method of claim 22, wherein only the user 
system can forward the at least one user-supplied risk parameter communicated by the 
third party host application to the risk filter routine. 
Tozzoli and Lynch disclose: 
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"...the trade system compare<s> a buyer's proposed purchase order 
with the buyer's pre-established account parameters or criteria stored in 
storage..." (col. 6, lines 37-43), where "criteria" is account parameter 
thresholds provided by the funder (col. 5, lines 57-60) 

Regarding claims 3. 4. 6. 9. 16 and 27: 

(Claim 3) The computer-implemented method of claim 1 , wherein the risk filter routine 
includes the steps of: generating an available balance for the Counterparty based upon 
the at least one user-supplied risk parameter, payments made by the account holder, 
and payments received by the account holder; and reading the first instruction from the . 
payment queue of the payment bank system; determining whether to selectively reject 
payment authorized by the first instruction based upon the available balance. 
(Claim 4) The computer-implemented method of claim 3, wherein payment authorized 
by the first instruction is rejected in the event that the amount of payment authorized by 
the first instruction exceeds the available balance. 

(Claim 6) The computer-implemented method of claim 3, wherein the available balance 
is computed over a given time period based upon payments made by the account 
holder in the given time period and payments received by the account holder in the 
given time period. 

(Claim 9) The computer-implemented method of claim 6, further comprising the steps 
of: receiving updates to payments made by the account holder in the given time period; 
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and receiving updates to payments received by the account holder in the given time 
period; and updating the available balance to reflect such updates. 
(Claim 16) The computer-implemented method of claim 1, wherein the at least one 
user-supplied risk parameter comprises a clean payment limit. 

(Claim 27) The computer-implemented method of claim 1, wherein said risk filter routine 
cooperates with other payment processing operated by said payment bank to determine 
whether to selectively reject payment authorized by the first instruction. 
Tozzoli and Lynch disclose: 

A payment can be rejected if it exceeds a credit limit balance (col. 1 1 , 
lines 59r67 and col. 12, lines 1-4). "...the trade system converts it to an 
actual or original purchase order, stores it as purchase order data in 
storage.., updates buyer and seller account data stored in 
storage.... notifies the funder and is then ready to filter data representing 
subsequent actions against the original purchase order data." (col. 8, lines 
12-18) Presumably updating buyer and seller account data would involve 
creating an available balance from the credit limit (risk parameter) and 
reading the first (and subsequent) instructions from the purchase order. 
The system is able to reject payments (col. 7, lines 64-67 and col. 8, lines 1- 
3). 



Regarding claim 5: 



Application/Control Number: 10/007,179 Page 9 

Art Unit: 3693 

The computer-implemented method of claim 3, wherein the first instruction is returned to 
the payment queue for later re-evaluation in the event that the amount of payment 
authorized by the first instruction exceeds the available balance. 

Tozzoli and Lynch disclose: 

"If the proposed purchase order does not meet the filtering criteria, 

the buyer may revise its terms..." (col. 7, lines 64-67 and col, 8, lines 1-3). 

Doing this effectively returns the instruction to the payment queue. 

Regarding claim 7: 

The computer-implemented method of claim 6, further comprising the steps of: receiving 
user-supplied updates to the at least one user-supplied risk parameter; and updating 
the available balance to reflect such user-supplied updates. 

Tozzoli and Lynch disclose: 

"As the purchase order is filled... the trade system adjusts account 

parameters to reflect the remaining outstanding portion of the purchase 

order." (col. 8, lines 30-36) 

Regarding claims 8, 11, 12, 35, 39, 42, 44 and 47: 

(Claim 8) The computer-implemented method of claim 7, further comprising the steps 
of: generating the user-supplied updates on a user system and communicating the 
user^supplied updates to the risk filter routine. 
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(Claim 11) The computer-implemented method of claim 6, further comprising the step of 
receiving user-supplied updates to the at least one user-supplied risk parameter for use 
in the risk filter routine. 

(Claim 12) The computer-implemented method of claim 1 1 , further comprising the steps 
off generating the user-supplied updates on a user system and communicating the user- 
supplied updates to the risk filter routine. 

(Claim 35) The computer-implemented method of claim 34, wherein the user-supplied 
second instruction is generated on a user system and communicated to a central 
server, which stores the user-supplied second instruction in a data server and forwards 
the user-supplied second instruction to a module integrated into the payment bank 
system that executes the risk filter routine. 

(Claim 39) The computer-implemented method of claim 38, wherein the third instruction 
is generated on a user system and communicated to a central server, which stores the 
third instruction in a data server and forwards third instruction to a module integrated 
into the payment bank system that executes the risk filter routine. 
(Claim 42) The computer-implemented method of claim 39, wherein the third instruction 
is generated by the payment bank host application. 

(Claim 44) The computer-implemented method of claim 43, wherein the third instruction 
is generated on a user system and communicated to a central server, which stores the 
third instruction in a data server and forwards the third instruction to a module integrated 
into the payment bank system that executes the risk filter routine. 
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(Claim 47) The computer-implemented method of claim 33, wherein the third instruction 

is generated by the payment bank host application. 
Tozzoli and Lynch disclose: 

A funder can "indicate various account parameter thresholds, also 
referred to herein as criteria, for the company to the trade system." (col. 5, 
lines 57-60) While updates are not discussed, is seems reasonable that the 
system could accommodate changes. This would also allow for the funder 
to provide multiple instructions against which purchase order could be 
filtered. Also, "The geographic distribution of the equipment comprising 
the trade system is also not critical to the present invention." (col. 5, lines 
14-15) Therefore the payment bank could generate the instructions. 

Regarding claim 10: 

The computer-implemented method of claim 9, wherein updates to payments made by 
the account holder and updates to payments received by the account holder are 
received through data interchange with existing payments confirmation services. 

Tozzoli and Lynch disclose: 

System allows for fund transfers using conventional electronic 

transfer networks (col. 9, lines 34-43), which would presumably supply this 

information to the trade system. 



Regarding claim 13: 
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The computer-implemented method of claim 1, wherein the risk routine is executed by a 
module integrated into the payment bank system. 

Tozzoli and Lynch disclose: 

The filtering process is stored in the data processing system (col. 4, 

lines 4-13), where the geographic distribution of the equipment comprising 

the trade system is not critical (col. 5, lines 14-16), therefore, it could be 

integrated with a payment bank system . 

Regarding claim 14: 

The computer-implemented method of claim 1 , wherein the risk filter routine is executed 
by a module that communicates to the payment bank system via an application-to 
application interface which translates data formats between the module and the 
payment bank system. 

Tozzoli and Lynch disclose: 

"...the system transmits data notifying the seller's bank... to request 
payment from the funder." (col. 9, lines 36-40) This indicates the system 
and the bank are able to exchange data with each other. 

Regarding claims 15, 17, 18, 25 and 26: 

(Claim 15) The computer-implemented method of claim 13, wherein the at least one 
user-supplied risk parameter is generated on a user system and communicated to a 
central server, which stores the at least one user-supplied risk parameter in a data 
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server and forwards the at least one user-supplied risk parameter to the module 
integrated into the payment bank system that executes the risk filter routine. 
(Claim 17) The computer-implemented method of claim 1 , wherein the at least one 
user-supplied risk parameter is associated with each payment-based transaction 
wherein payment is made from the account holder to the Counterparty. 
(Claim 18) The computer-implemented method of claim 17, wherein the at least one 
user-supplied risk parameter is selected from the group consisting of: 

(i) currency associated with each payment-based transaction, 

(ii) payment type associated with each payment-based transaction, and 

(iii) a Clean Payment Limit associated with each payment-based transaction. 
(Claim 25) The computer-implemented method of claim 1, wherein the Counterparty 
comprises a beneficiary of the payment-based transaction. 

(Claim 26) The computer-implemented method of claim 25, wherein the Counterparty 
further comprises an intermediary to the beneficiary of the payment-based transaction. 
Tozzoli and Lynch disclose: 

"A system stores criteria specified by a funder relating to trade 
transactions for buyers and sellers (Abstract)." Also, "The system 
compares the criteria with a proposed purchase order to determine 
whether the system can generate a payment guarantee on behalf of the 
funder for the buyer to the seller." "When the appropriate conditions for 
payment are met, the system issues a funds transfer instruction to transfer 
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payment from the buyer to the seller." Criteria can include credit limits 
(col. 5, lines 61-62). Intermediary bank is disclosed in Fig. 1. 

Regarding claim 19: 

The computer-implemented method of claim 17, wherein the at least one user-supplied 
risk parameter is associated with a first identifier that identifies the account holder and a 
second identifier that identifies the Counterparty on the payment transaction. 

Tozzoli and Lynch disclose: 

Risk parameters are associated with the buyer, the account holder, 

and seller for a payment transaction (col. 10, lines 42-55) 

Regarding claim 20: 

The computer-implemented method of claim 1, wherein the account holder comprises a 
user with a pre-existing account relationship with the payment bank. 

Tozzoli and Lynch do not discuss the need to create new accounts 
or relationships to use their system, therefore, it is reasonable to assume 
pre-existing account relationships with payment banks are acceptable. 

Regarding claims 21 and 22: 

(Claim 21) The computer-implemented method of claim 20, wherein the account holder 
further comprises a third party, and wherein the user is acting on behalf of the third 
party. 
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(Claim 22) The computer-implemented method of claim 21 , wherein said third party 
executes a third party host application that generates the at least one user-supplied risk 
parameter and communicates the at least one user-supplied risk parameter and 
associated information to a user system, which forwards the at least one user-supplied 
information to the risk filter routine. 
Tozzoli and Lynch disclose: 

"Generally, f under guarantees payment for transactions processed 
by the trade system between an approved buyer and a seller which satisfy 
the funder's predetermined criteria." (col. 5, lines 35-38) "To obtain access 
to the system, companies wishing to act as buyers and sellers go through 
an application process supervised by the f under." (col. 5, lines 46-50) 
Creation of a risk parameter(s) requires the third party to fill out an 
application. 

Regarding claim 28: 

The computer-implemented method of claim 1 , wherein the risk filter routine cooperates 
with a domestic payment system operated by said payment bank, such that the first 
instruction is filtered by said risk filter routine for compliance with a risk profile generated 
from the at least one user-supplied risk parameter. 

Tozzoli and Lynch disclose: 

"The trade system receives inputs from and supplies outputs to 

buyers, sellers, funders and various parties involved in a trade transaction, 
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such as... banks and the like..." (col. 4, lines 51-55). Therefore, the funder, 
which specifies trade transactions for a buyer and seller (Abstract), and 
provides risk parameters, could interface with domestic banks. 

Regarding claim 29: 

The computer-implemented method of claim 1, further comprising the step of: for each 
given first Instruction, when processing by the risk filter routine rejects payment 
authorized by the given first instruction, adding the given first instruction to a cache of 
first instructions. 

Tozzoli and Lynch disclose: 

"The system retains and stores copies of all electronic documents 
which it processes... and/or performs filtering." (col. 16, lines 49-51) Also, 
"The trade system of the present invention keeps track of outstanding 
purchase orders, and adjusts the account parameters corresponding to the 
criteria established by the funder... based on relevant outstanding 
purchase orders..." (col. 10, lines 1-6) Therefore, rejected first instructions 
could be tracked. 

Regarding claim 30 and 50: 

(Claim 30) The computer-implemented method of claim 1, further comprising the step of 
communicating notification of rejection or success of at least one payment authorized by 
the first instructions stored in a cache. 



Application/Control Number: 10/007,179 Page 17 

Art Unit: 3693 

(Claim 50) The computer-implemented method of claim 1 , wherein users and the 
payment bank can also generate and receive payments-related notifications, inquiries, 
messages and reports. 

Buyer can receive electronic notices if payment guarantee cannot be 

authorized by the system, such as if purchase exceeds a credit limit 

balance (col. 12, lines 32-38). 

Regarding claim 31: 

The computer-implemented method of claim 30, wherein said notification is 
communicated via messaging services operably coupling the user system, a central 
system, and the payment bank system. 

Tozzoli and Lynch disclose: 

"The users of the trade system communicate with the system using 

their own or third party conventional telecommunications equipment." (col. 

4, lines 58-62 and Fig. 4) Messaging services are disclosed, for example, 

"...system receives an advisory message..." (col. 15, lines 1-3). 

Regarding applicant claim 32: 

(Claim 32) The computer-implemented method of claim 31, wherein a third party 
application is operably coupled to the payment bank system, and wherein said 
notification is forwarded to said third party application by said payment bank system. 
Tozzoli and Lynch disclose: 
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"To obtain access to the system, companies... go through an 
application process supervised by a funder." (col. 5, lines 46-48) To 
accomplish would require they are operably coupled to the funder. 

Regarding claim 33: 

The computer-implemented method of claim 30, wherein said notification is generated 
in the event that the Counterparty fails to make expected payments for a pre- 
determined period of elapsed time. 
Tozzoli and Lynch disclose: 

"...the trade system automatically generates scheduling reminder data." 
(col. 17, lines 36-37) 

Regarding claim 34: 

The computer-implemented method of claim 1 , further comprising the steps of: receiving 
a user-supplied second instruction that identifies an account holder and Counterparty; 
and in response to receipt of the user-supplied second instruction, suspending all 
payments from the account holder to the Counterparty as identified by the second 
instruction. 

Tozzoli and Lynch disclose: 

"If the proposed purchase order does not meet the filtering criteria, 

the buyer may revise its terms... (col. 7, lines 64-65). This would allow for 

suspension of payments if necessary. 
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Regarding claim 36. 40 and 45: 

(Claim 36) The computer-implemented method of claim 35, wherein a third party 
executes a third party host application that generates the user-supplied second 
instruction and communicates the user-supplied second instruction to a user system, 
which forwards the user-supplied second instruction to the module integrated into the 
payment bank system via the central server. 

(Claim 40) The computer-implemented method of claim 39, wherein a third party 
executes a third party host application that generates the third instruction and 
communicates the third instruction to a user system, which forwards the third instruction 
to the module integrated into the payment bank system via the central server. 
(Claim 45) The computer-implemented method of claim 44, wherein a third party 
executes a third party host application that generates the third instruction and 
communicates the third instruction to a user system, which forwards the third instruction 
to the module integrated into the payment bank system via the central server. 
Tozzoli and Lynch disclose: 

A company (third party) may have software and computer for access 
to the trade system (col. 6, lines 8-19), and "The buyer can then revise the 
terms of the proposed purchase order... in the form of data entry to the 
system as a proposed purchase order for filtering by the system." (col. 12, 
lines 40-13 and Fig. 2A) Presumably this could be done for multiple 
instructions. Also, "The geographic distribution of the equipment 
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comprising the trade system is also not critical to the present invention." 
(col. 5, lines 14-15) Therefore the payment bank could have a module 
integrated into their system. 

Regarding claim 37, 41, 46: 

(Claim 37) The computer-implemented method of claim 34, further comprising the step 
of: communicating notification confirming receipt and implementation of the user- 
supplied second instruction to the payment bank, core server, user and third party, if 
any. 

(Claim 41) The computer-implemented method of claim 39, further comprising the step 
of: returning notification confirming receipt and implementation of the third instruction to 
the payment bank, central server, user and third party, if any. 

(Claim 46) The computer-implemented method of claim 34, further comprising the step 
of: returning notification confirming receipt and implementation of the user-supplied third 
instruction to the payment bank, core server, user and third party, if any. 

"...the funder indicates various account parameters thresholds, also 
referred to herein as criteria, for the company to the trade system." (col. 5, 
lines 57-60) The system provides a report showing payment instructions 
(col. 10, lines 42-55) against the credit limit monitored by a funder ("When 
the proposed purchase order meets the filtering criteria, the trade system 
forwards the purchase order in the form of data to the seller with an 
indication of the funder's payment guarantee." (col. 7, lines 54-58)). 
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Regarding claims 38, 43, and 64: 

(Claim 38) The computer-implemented method of claim 1 , further comprising the steps 
of: receiving a third instruction that identifies a particular first instruction; and in 
response to receipt of the third instruction, disabling processing of the risk filter routine 
for the particular first instruction. 

(Claim 43) The computer-implemented method of claim 1 , further comprising the steps 
of: receiving a third instruction that identifies a particular Counterparty; and in response 
to receipt of the third instruction, disabling processing of the risk filter routine with 
respect to any first instruction authorizing payment from the account holder to the 
Counterparty. 

(Claim 64) The computer-implemented method of any of claim 34, further comprising 
the steps of: receiving a user-supplied third instruction that identifies an account holder 
and Counterparty; and in response to receipt of the user-supplied third instruction, 
reinstating payments from the account holder to the Counterparty as identified by the 
third instruction by countermanding a previously communicated second instruction. 

"...parties may elect to proceed with the transaction using other non- 
system avenues for payment guarantees..." (col. 7, line 67 and col. 8, lines 
1-3). This would effectively disable the filter routine. Presumably this could 
be done on a third instruction, assuming the purchase order does not meet 
the initial filter and the buyer passes it on to the seller (a payment (first) 
instruction fails to meet criteria, trade system generates an error (non- 
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payment) instruction, and buyer modifies (first) instruction (which creates 
third instruction) and sends it to seller). 

Regarding claim 48: 

The computer-implemented method of claim 1 , further comprising the step of: using 
digital certification to establish access authority and usage constraints of the risk filter 
routine. 

Tozzoli and Lynch disclose: 

"The trade system administrator.. .may establish additional criteria 
(e.g. certain documentary certification required for trade in services)." (col. 
6, lines 8-12) 

Regarding claim 49: 

The computer-implemented method of claim 1, wherein data transmissions are 

encrypted for security purposes. 

Tozzoli and Lynch disclose: 

Passwords and other types of security may be used with the system 
which can be used "...to authenticate and/or encode its electronic 
document submissions to the systems..." (col. 5, lines 21-34). 



Regarding claim 51: 
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The computer-implemented method of claim 1 , wherein users can request and receive 
multi-currency reports from a plurality of Payment Banks acting on their behalf. 

Tozzoli and Lynch disclose: 

Template data may include currency conversion rates, (col. 11, lines 

26-31) While it is not disclosed where this information comes from, it 

seems reasonable to assume Payment Banks in foreign country would 

provide the information. 

Regarding claim 52: 

The computer-implemented method of claim 1 , wherein human-accessibility is provided 
by browser interfaces and data-accessibility is provided by electronic data interchange 
formats. 

Tozzoli and Lynch disclose: 

"The remote locations may be a third party network..., a front end... 

such as a personal computer with trade system software..." (col. 5, lines 6- 

10). 

Regarding claim 53: 

The computer-implemented method of claim 1 , wherein said account holder and 
Counterparty comprise multiple entities that are deemed to share correlation in 
payment risk assessment, wherein the multiple entities are identified by an aggregate 
identifier. 
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Tozzoli and Lynch disclose: 

Buyer can obtain an account summary report, which would 
aggregate multiple entities with a correlation in payment risk assessment 
(col. 10, lines 42-55). 

Regarding claim 54: 

The computer-implemented method of claim 1 , further comprising the steps of: 
recording various type of information, including identification of Users, identification of 
Third Parties, identification of Payment Banks, identification of Counterparties, 
identification of Currencies, specification of the Clean Payment Limit, and Payment 
Type identification. 

Tozzoli and Lynch disclose: 

Various information can be inserted into a template, such as third 

party ID, payment limits and type of payments, (col. 11, lines 23-31) 

Regarding claim 55: 

The computer-implemented method of claim 1 , wherein selective rejection of payment 
authorized by the first instruction reduces payment risk arising from default by the 
Counterparty and any liquidity risk and system risk arising therefrom in like amount. 
Tozzoli and Lynch disclose: 
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An order "will be rejected by the trade system due to inadequate 
available credit for the buyer." (col. 12, lines 25-31) This reduces risk of 
default. 

Regarding claim 56: 

The computer-implemented method of claim 49, wherein the data transmissions occur 
over a virtual private network that uses the Internet and other internet protocol 
telecommunications networks. 

Tozzoli and Lynch disclose: 

"The central facility communicates with remote locations through 
telecommunications links..." (col. 5, lines 2-10) "The remote locations may 
be a third party network..." Third party networks can be virtual private 
networks and the Internet uses telecommunication links. 

Regarding claim 57: 

The computer-implemented method of claim 1 , wherein the risk filter routine controls the 
flow of payment messages from the payment queue to a domestic payment system for 
clearance. 

Tozzoli and Lynch disclose: 

The risk filter would control through the purchase order (via dates as 

one example) the order of payments to be made (col 10, lines 42-55). 
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Regarding claim 62: 

The computer-implemented method of claim 1 , wherein the risk filter routine operates, in 
the event that there are multiple Counterparties of an account holder for a given first 
instruction, to iteratively evaluate the given first instruction for compliance with the at 
least one user-supplied risk parameter as applicable to each Counterparty. 

Tozzoli and Lynch disclose: 

The system is capable of using a risk factor, such as credit limit, 

against multiple parties in an iterative manner (col. 10, lines 42-55) 

Regarding claim 63: 

The computer-implemented method of claim 1, wherein the Counterparty comprises one 
of payment beneficiary and intermediary. 

Tozzoli and Lynch disclose: 

The seller can instruct the system to accept the best buyer's offer 

(col. 6, lines 63.-67 and col. 7, lines 1-213), therefore, the system and seller 

are acting as one. 

Claim Rejections - 35 USC § 103 

8. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 
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9. The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 
USPQ 459 (1966), that. are applied for establishing a background for determining 
obviousness under 35 U.S.C. 1 03(a) are summarized as follows: 

1 . Determining the scope and contents of the prior art. 

2. Ascertaining the differences between the prior art and the claims at issue. 

3. Resolving the level of ordinary skill in the pertinent art. 

4. Considering objective evidence present in the application indicating 
obviousness or nonobviousness. 

10. Claims 24 and 58-61 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over U.S. Patent No. 5,717989 to Tozzoli and Lynch in view of U.S. Patent No. 
6,076,074 to Cotton, etal.. 

Regarding claims 24 and 58-61: 

(claim 24) The computer-implemented method of claim 19, wherein the first and second 
identifiers are Bank Identifier Codes or an aggregation of such codes, 
(claim 58) The computer-implemented method of claim 1 , wherein the first instruction 
comprises a S.W.I. FT. payment transaction. 

(claim 59) The computer-implemented method of claim 1 0, wherein updates to the 
payments made by the Counterparty and updates to payments received by the 
Counterparty comprise S.W.I. FT. messages. 

(claim 60) The computer-implemented method of claim 1 , wherein the risk filter routine 
interoperates with a plurality of payment channels for any given currency. 
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(claim 61) The computer-implemented method of claim 60, wherein said plurality of 
payment channels includes net payment systems, real-time gross payment systems and 
intra-bank book transfers. 

Although Tozzoli and Lynch disclose an international trade system that uses 
filters to mitigate risk, and they disclose issuing and paying banks, they do not 
provide details regarding bank activity. 

Cotton, et al., in the same filed of endeavor of mitigating international trade 
risk teaches "Often a bank will send a payment order over the network operated 
by the Society for Worldwide Interbank Financial Telecommunications 
("S.W.I.F.T."), with the payment of the sender's obligation effected through 
adjustment of correspondent balances or other means." (col. 5, lines 35-40) They 
also disclose net and real-time gross settlement systems (col. 7, lines 36-39) and 
use of codes established by the Federal Reserve Bank (col. 3, lines 16-19). 
Therefore, it would have been obvious to one of ordinary skill in the art at the 
time of invention to provide banking details such as S.W.I. FT., interbank 
settlement systems, and bank codes motivated by the fact that Cotton, et al., is 
also drawn to a method of reducing foreign payment risk and the trade system 
could be added separately to their system to augment risk reduction. 
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Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Kenneth L. Bartley whose telephone number is (571) 
272-5230. The examiner can normally be reached on Monday through Friday, 8:00 - 



If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Jagdish Patel can be reached on (571) 272-6748. The fax phone number 
for the organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 
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